…ot a 404 that blames the route (#4093 follow-up)

Two different facts were being answered with whatever each domain happened to
reach for, and only `mcp` told them apart:

  - The route is not there. `/mcp` when the server is disabled for the
    environment; `/analytics` when the service is unserveable, because
    dispatcher-plugin gates the MOUNT and never registers those paths (#4000).
    A path the server does not expose is a 404 from the host's own router.
    Unchanged — that half was already right.

  - The route is there; the implementation is not. Every unconditionally
    mounted domain. The request reached a handler with nothing to delegate to.
    That is 501, and it is what changes here.

`/automation` and `/notifications` returned `{ handled: false }`. That looks
neutral, but it is not a fall-through: the dispatcher plugin's single exit
turns it into `404 ROUTE_NOT_FOUND` with the hint "No handler matched this
request. Check the API discovery endpoint for available routes." Both halves
are false. A handler DID match — it just had nothing behind it — and discovery
correctly does not list the route, so the hint points at a page that will never
mention it. An operator reads that as a routing bug and goes looking for one
that does not exist.

`/ui` answered 503, which claims the condition is temporary. An uninstalled
MetadataPlugin does not become installed by retrying. `/ai` answered 404 for
the same mounted-but-unimplemented case.

The refusal is written once (`domains/unavailable.ts`) and carries the same
remedy sentence discovery reports for the slot, via `serviceUnavailableMessage`
from the table #4204 added — so the wall and the discovery entry cannot drift
into naming different fixes. `POST /api/v1/automation` on a stack without the
service now answers `501 Install @objectstack/service-automation to enable`.

`/ai` keeps a local message deliberately: its real provider ships outside this
workspace as a Cloud/EE package, so CORE_SERVICE_PROVIDER — verified against
workspace packages by check:service-providers — records `null` for that slot
and the shared sentence would say "nothing ships", which is wrong. That gap
between "no workspace package" and "no package" is worth knowing about; the
override keeps this change honest without widening the guard's contract here.

Deliberately unchanged: analytics's route-mount gate (a genuinely absent path);
mcp's 404-vs-501 pair, which is the model this generalizes; the `handled: false`
at the END of each domain, which means "no sub-route matched" and is a true
404; `GET /ai/agents`'s empty-list 200 (a deliberate courtesy for the console's
per-navigation poll); and `/ai`'s `503 routes not yet initialized`, a different
condition — service present, internal state unready — that may genuinely be
transient.

Tests: nine pinned the old answers and are updated to the new one, with the
part that actually mattered preserved in each — the automation stub is still
asserted NEVER CALLED, the notifications stub's `listInbox` likewise, and
`/ai/agents` still returns its empty list. route-parity's integration
assertion keeps its invariant (not advertised ⟹ not served, #3369) and now
states why 501 expresses it better than the 404 it used to assert.

Verified: full `pnpm test` 132/132 tasks; runtime 955; build 71/71; pnpm lint
and every check:* gate clean (route-envelope needed the new domains/ file
declared as handBuilt: 0 — it answers only through deps.error, which is that
check's own thesis applied to the refusal itself).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UNGqBQcdJ2RYHtWgntJ9B

The drift check flagged 18 docs — the blast radius of touching runtime — and
none of them claimed the statuses this PR changes. But one already documented
the rule for a single surface: `/graphql` is described as "route is wired but
bring-your-own service: returns 501 unless an implementation is registered".
That was the house convention all along; this PR makes it hold everywhere, so
the API docs should state it as a rule rather than as a GraphQL quirk.

Added to the Discovery section, where a reader asks the question it answers:
404 means the route is not mounted (analytics' gated mount, mcp when disabled),
501 means it is mounted with nothing behind it, the 501 body names the package
to install, and nothing answers 503 for a missing capability — that status is
for genuinely transient states like a still-booting kernel on /ready.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UNGqBQcdJ2RYHtWgntJ9B